Reference discussion in #849

this looks somewhat correct but tls.rs is a lot to review. are you sure that's all necessary? I can't help but notice it's also AI

It looks long, mostly because I wanted to make sure that this wasn't going to lead to anyone getting locked out due to the feature. There's several things that it does. It sets the IP of the CN based on the IP the device is reporting, and if that fails it uses the device default (192.168.1.1 for orbic, etc). That way the IP at least matches the IP you're connecting to over wifi. The cert may not be validated through the trust chain in the browser, but it's CN at least matches.

It always checks the certificate is not junk, and if it is corrupted or bad in some way it attempts to regenerate the certificate up to 3 times. Failing that it shows a clear message to the user and falls back to HTTP mode. This means nobody getting stuck with HTTPS broken.

We're also setting the permissions for the key to make it secure as possible (I know the device is vulnerable af but we may as well stick to best practices where possible).

The rest of the length of tls.rs is just the tests, I shouldn't have them in that file that's my bad and I'll remove that. I did use Claude to help write some of this, although it was an actual collaboration not just a 'go do this'. I've also tested on actual hardware as well.

Now that I'm on lunch, let me see if I can simplify this a bit.

I did a rebase so it's cleaner; removed the code to dynamically get the IP, simplified the tests a bit.

The automated checks are acting up, I need to figure a way to get these to run locally.

Gah, don't have time for this now. I'll install act and run the pipelines locally when I can. Sorry about that folks.

Checks should all pass now